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PROCEDE DE TRANSMISSION DE FLUX DE DONNEES DEPENDANTS 



Le domaine de Tinvention est celui de la transmission de donnSes, sous la 
forme d'un ou plusieurs flux de donn£es constitu^s chacun d'unit6s de flux 
5 eiementaires. Plus pr6cis6ment, Finvention concerne l'optimisation du traitement 
de ces unites de flux eiementaires, lorsque celles-ci sont dependantes de, ou Her 
une ou plusieurs autres unites de flux. 

Lorsqu'un signal, par exemple de type multimedia, est transmis sur un 
canal unique et de fa$on synchrone, le traitement d'une unite de flux ne pose pas, 
10 ou peu, de problfeme. Les donn^es n6cessaires ont 6t6 re9ues pr6c6demment. 

Cela n'est pas le cas, en revanche, dans des systfemes asynchrones, pouvant 
mettre en oeuvre plusieurs canaux de transmission, et/ou plusieurs serveurs 
distribuant chacun une partie du signal utile. C'est par exemple le cas de la 
transmission, ou de la diffusion, sur un r6seau type IP. 
15 Dans ce cas, il arrive que Ton revive une unite de flux qui est sens6e en 

completer d'autres, qui n'ont pas et6 re?ues. II peut par exemple s'agir de donn€es 
d'enrichissement de donnees d'un niveau hierarchique superieur, les donn^es 
etant codees k Taide d'un codage hierarchique (un flux pouvant alors 
correspondre k un niveau hierarchique donn6). Le traitement des donn^es 
20 d'enrichissement va alors donner un r6sultat aieatoire, conduisant en general h une 
forte degradation du signal iestitu6, voire h un blocage complet du d£codeur. 

L'art anterieur en matifcre de synchronisation multimedia est represents 
essentiellement par les protocoles de transport bases sur RTP et par MPEG-4 
(Synchronization Layer). Dans l'approche utilisee, les mecanismes de 
25 synchronisation ont 6te principalement con$us pour synchroniser temporellement 
un flux audio et un flux video, afin qu'ils soient presentes sans decalage. Ces 
informations etaient vehicuiees au moyen d'un systfcme d'estampillage temporel 
(une horloge de reference, des estampilles de decodage et de presentation). 

Avec l'av&nement de codages hierarchiques, oH differents niveaux 
30 d'enrichissement temporel et spatial sont utilises afin de produire une trame 
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presentable, l'inventeur a constate qu'un nouveau besoin de synchronisation 
apparait. 

En effet, il est n^cessaire de synchroniser les flux avant leur decodage (et 
non pas seulement k leur presentation). Cette contrainte s'av&re plus complexe 
5 que la synchronisation de presentation car il est n€cessaire d'identifier quelles 
sont les unites necessaires au decodage d'une unite afin de produire une trame 
correcte. Un seul decalage peut rendre inutile tout un flux ainsi que tous les flux 
bases sur ce dernier, II s'agit la d'un probieme nouveau, et non evident, identifie 
par Tinventeur. 

10 Un probfeme similaire se pose lorsqu'une unite de flux re9ue doit etre 

decodee, ou decryptee, k 1'aide d' informations (par exemple une cie de decodage) 
que le terminal aurait dfi recevoir, mais qu'il n*a pas re$ues. A nouveau, le resultat 
du decodage sera au minimum inefficace, en general nuisible (en termes de signal 
restitue), et peut conduire au blocage du terminal. Dans les deux cas, un traitement 

15 inutile et nefaste aura et6 effectue. 

Un autre probl^me important rencontre dans les sysfemes de diffusion 
(« multicast » ou « broadcast ») est que les memes informations doivent Stre 
multidif fusees, pour permettre h un utilisateur se connectant h un instant 
quelconque de recevoir l'integralite du ou des flux qu'il a seiectionnes. Cet aspect 

20 specifique est dej& discute dans la demande de brevet EP-01 4600462, non encore 
publiee, aux noms des titulaires de la presente demande de brevet. Selon cette 
technique, le traitement est effectue au niveau du transport, ce qui impose un 
traitement de chaque unite de flux, tenant compte des specificites des differents 
types de transport. 

25 L'art anterieur en mati&re de representation multimedia dans des scenarii 

« broadcast » et « multicast » est decrit dans la specification du « carousel MPEG- 
4 ». Cependant un certain nombre de fonctionnalites sont interdites ou rendues 
extremement consommatrices en debit. Dans les deux scenarii de deiivrance 
consideres, il est necessaire de signaler des points d'entree k la presentation 
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multimedia & tout moment. Ceci se traduit par une repetition des donnees relatives 
a la description de la scfcne : sc6ne BIFS, textures. 

Dbs que le contenu multimedia devient riche, cette repetition simple n'est 
pas acceptable et conduit k des temps de teiechargement excessifs. Par ailleurs, 
5 cette specification ne permet pas de diffuser certains elements multimedia (clips 
audio/video de courte duree). 

L' invention a notamment pour objectif de pallier ces differents 
inconvenients de retat de Tart. 

Plus precisement, un objectif de Finvention est de fournir une technique 
10 permettant de g6rer efficacement des unites de flux, lorsque celles-ci dependent 
de, ou sont liees une ou plusieurs autres unites de flux. 

Notamment, un objectif de Finvention est de fournir une telle technique, 
qui permette la gestion de flux lies, en particulier dans le cas de donnees codees & 
Faide d'un codage hierarchique, ou un codage comprenant un codage associant 
15 des donnees de base et des donnees d'enrichissement. 

Un autre objectif de Finvention est de fournir une telle technique, 
permettant d'assurer efficacement la gestion du decodage, ou du decryptage, 
d' unites de flux. 

Encore un autre objectif de Finvention est de fournir une telle technique, 
20 qui permette d'optimiser la transmission de scenarii multidiffuses, et notamment 
de reduire la quantite de ressource utilisee, sans reduire la qualite de la reception. 

I/invention a pour objectif, en d'autres termes, d'optimiser les traitements 
effectues, dans les terminaux, tant en quantite qu'en qualite. 

Ces objectifs, ainsi que d'autres qui apparaitront par la suite, sont atteints 
25 selon Finvention & Faide d'un precede de transmission d*au moins un flux de 
donnees vers au moins un terminal, le ou lesdits flux etant organises en unites de 
flux. Selon Finvention, au moins certaines desdites unites de flux comprennent au 
moins un pointeur pointant vers au moins une unite de flux dudit flux ou d*un 
autre flux susceptible d* avoir ete re$ue precedemment dans un terminal, dite unite 
30 anterieure n6cessaire, de fa$on qu'un traitement de ladite unite de flux ne soit pas 
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effectue, dans ledit terminal, si la ou lesdites unites anterieures necessaires n'ont 
pas 6\6 regues. 

On dispose ainsi d'un systfcme de synchronisation logique, 
permettant de faciliter la gestion des unites de flux, de limiter les traitements dans 
5 les terminaux, d'ameiiorer la qualite de restitution,. . . 

Le format de donnees ainsi d£fini, selon Tinvention, peut etre mis en 
oeuvre non seulement pour la transmission et la reception de flux, mais £galement 
pour leur diffusion, leur enregistrement et leur stockage. 

L'invention repose done notamment sur 1* identification du problfcme 
10 nouveau de la synchronisation « arrfere » des flux ou des unites de flux, et sur 
l'observation non evidente que la solution la plus efficace est de ne pas traiter les 
unites de flux lorsque Ton ne dispose pas de tous les elements pour le faire. II 
apparait en effet preferable, en termes de restitution de signal, d'ignorer une unite 
de flux plutot que d'en effectuer un d£codage qui conduira k une deterioration du 
15 signal restitue, voire k un blocage complet du terminal. 

De fa^on avantageuse, le precede de Tinvention comprend la transmission 
d'au moins deux flux de donn6es transmis separ6ment, une unite de flux d'un 
premier flux pointant vers au moins une unite anterieure necessaire d*au moins un 
second flux, ladite unite de flux du premier flux comprenant des donnees 
20 d'enrichissement des donnees contenues dans le ou lesdits seconds flux. 

Dans ce cas, lesdits flux de donnees peuvent avantageusement 
correspondre k des niveaux hierarchiques diff6rents d*un codage hierarchique, le 
traitement d*une unite de flux d'un niveau hierarchique donne n'etant effectue que 
si les unites de flux du ou des niveaux hierarchiques inferieurs correspondants ont 
25 ete re9us. 

Ladite unite de flux peut pointer sur au moins une unite anterieure, 
definissant une sequence d'unites anterieures necessaires. 

Selon une caracteristique avantageuse de Tinvention, au moins un desdits 
pointeurs permet de retrouver au moins une unite anterieure necessaire 
30 comprenant des donnees permettant le decodage et/ou le d6cryptage de Tunite de 
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flux consider6e. 

Pr6f£rentiellement, la ou lesdites unites anterieures n6cessaires 
comprennent des donn6es permettant a un terminal de decider si les donn6es 
d'une unite de flux consider doivent etre d6cod6es et/ou decryptees, puis 
5 affichees apr&s decodage. 

Selon une autre mise en ceuvre avantageuse, au mo ins un desdits pointeurs 
pointent vers des donn^es susceptibles d'etre connues dudit terminal, de fa?on que 
ce dernier puisse decider de sa capacity ou de son incapacity & traiter i'unite de 
flux correspondante. 

10 De fagon avantageuse, selon un autre aspect de l'invention, au moins une 

desdites unites de flux comprend au moins un pointeur pointant vers au moins une 
unit6 de flux dudit flux ou d'un autre flux, susceptible d'etre re$ue prochainement. 

Pr6f6rentiellement, la ou lesdites unites de flux susceptible d'etre re?ue 
prochainement poss&de en marqueur, permettant de faire un lien avec le ou lesdits 

15 pointeurs. 

Ainsi, avantageusement, les pointeurs d'au moins deux unites de flux 
similaires transmises & des instants distincts peuvent pointer vers une m8me unite 
de flux susceptible d'etre re9ue prochainement. 

De fa9on pr6f6rentielle, le precede de 1' invention met en ceuvre un 
20 indicateur indiquant le rdle du ou des pointeurs, parmi au moins deux des roles 
appartenant au groupe comprenant : 

designation d'au moins une unite de flux anterieure devant £tre 
d6cod6e pour permettre la prise en compte de I'unite de flux 
consider ; 

25 - designation d'au moins une unite de flux anterieure comprenant des 

donn6es n6cessaires au decodage et/ou au d£cryptage de I'unite de 
flux consid£r£e, et/ou d'une reference £ un 6tat d'un systfcme de 
protection ; 

designation d'au moins une unite de flux posterieure. 
30 Avantageusement, au moins certaines desdites unites de flux comprennent 
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un descripteur de d^pendance, d6finissant ledit rdle. 

De fafon avantageuse, au moins certaines desdites unites de flux 
comprennent un marqueur de d^pendance, permettant son identification en tant 
qu'unite anterieure n6cessaire et/ou un marqueur d'identification de ladite unite de 
5 flux dans ledit flux. 

Pr6f6rentiellement, le precede de Finvention est mis en oeuvre au niveau 
synchronisation, de fa?on qu'aucun traitement pr6alable d*une unite de flux re$ue 
ne soit n£cessaire. 

L'invention concerne 6galement un ou plusieurs flux de donn£es transmis 
10 selon le proc&te de transmission d6crit ci-dessus. Comme ddja mentionnd, un tel 
format de donn6es peut gtre utilise pour la transmission, la diffusion, la reception, 
renregistrement (par exemple via un magneto scope ou un enregistreur de disques 
optiques) et le stockage de donn£es (par exemple sur un CD-ROM, une bande, un 
serveur distant... ). 

On notera £galement que Tinvention permet de combiner aisdment 
plusieurs de ces aspects. Par exemple, certains flux peuvent etre diffuses, et 
d'autres fournis sur un CD-ROM, ou un serveur, la connaissance des seconds 
6 tant n^cessaires pour decoder (ou optimiser) les premiers. 

Un tel flux de donn^es est organist en unites de flux transmises 
indgpendamment les unes des autres, au moins certaines desdites unites de flux 
comprenant au moins un pointeur pointant vers au moins une unite de flux dudit 
flux ou d'un autre flux susceptible d* avoir 6te re$ue pr£c6demment dans un 
terminal, dite unite anterieure n6cessaire, de fa$on qu'un traitement de ladite unite 
de flux ne soit pas effecUte, dans ledit terminal, si la ou lesdites unites anterieures 
n6cessaires n'ont pas 6t6 re?ues. 

L* invention concerne dgalement les serveurs de donnges destinies k Stre 
transmises vers au moins un terminal, sous la forme d*au moins un flux de 
donn6es organist en unites de flux transmises indSpendamment les unes des 
autres, au moins certaines desdites unites de flux comprenant au moins un 
pointeur pointant vers au moins une unite de flux dudit flux ou d'un autre flux 
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susceptible d'avoir 6t6 re?ue pr6c6demment dans un terminal, dite unite ant£rieure 
n€cessaire. 

L'invention concerne encore les terminaux apte k recevoir au moins un flux de 
donn£es organist en unites de flux transmises ind£pendamment les unes des 
5 autres, au moins certaines desdites unites de flux comprenant au moins un 
pointeur pointant vers au moins une unite de flux dudit flux ou d'un autre flux 
susceptible d'avoir 6t6 re$ue pr£c6demment dans un terminal, dite unite anterieure 
n6cessaire. 

L'invention concerne egalement les precedes de reception d'au moins un 
10 flux de donnees organist en unites de flux transmises independamment les unes 
des autres, au moins certaines desdites unites de flux comprenant au moins un 
pointeur pointant vers au moins une unite de flux dudit flux ou d'un autre flux 
susceptible d'avoir €l€ re$ue pr6c6demment dans un terminal, dite unite anterieure 
n^cessaire, et le precede de reception comprend les Stapes suivantes : 
15 - analyse du ou desdits pointeurs d'une unite de flux ; 

traitement de ladite unite de flux si la ou lesdites unites anterieures 
n^cessaires ont 6x6 re$ues. 
L'invention concerne enfin les utilisations du precede de transmission, en 
particulier pour une des applications appartenant au groupe comprenant : 
20 - diffusion systematique d'un message avant acc£s k un programme 

s£lectionn6 par un utilisateur ; 

accfes conditionnel & un niveau de quality particulier et/ou & une 
option particuli&re d'un programme ; 
t6l6 vision interactive. 

25 D'autres caract&istiques et avantages de l'invention apparaitront plus 

clairement h la lecture de la description suivante d'un mode de realisation 
pr£fSrentiel de l'invention, donne k titre de simple exemple illustratif, et des 
dessins annexes, parmi lesquels : 

la figure 1 illustre le principe de la gestion de la d€pendance d'un 

30 flux de donnees par rapport k un autre, selon l'invention ; 
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la figure 2 prgsente une mise en ceuvre de Tinvention, dans le cas 
de la diffusion d'un flux (« broadcast ») et de sa reception par deux 
terminaux, sous la forme de sessions d6cal6es dans le temps ; 
la figure 3 illustre le cas d'une synchronisation U6e au d£codage, ou 
5 au decryptage, d'une unite de flux (IPMP) ; 

la figure 4 presente une variante du cas de la figure 3, avec deux 
points de protection (d£codage et rendu). 
Le mode de realisation pr^fSrentiel d6crit ci-apr£s concerne notamment la 
transmission de flux, dans un systeme multimedia, notamment du type MPEG4. 
10 1. ranpels sur la technique anterieure : 

La technique anterieure ne permet ni de prendre en compte la transmission 
efficace (en termes de debit et de fonctionnalite) de scfenes multimedia dans des 
scenarii multicast ou bien broadcast ni la synchronisation de flux interdependants 
des elements lies au contenu de type clefs de contrdle d'accfcs. 
15 1 .1 representation multimedia dans des scenarii broadcast et multicast 

Une solution est proposee dans la specification du « carousel MPEG-4 ». 
Cependant un certain nombre de fonctionnalites sont interdites ou rendues 
extrSmement consommatrices en debit. Dans les deux scenarii de deiivrance 
consideres, il est necessaire de signaler des points d'entree h. la presentation 
20 multimedia h tout moment. Ceci se traduit par une repetition des donnees relatives 
& la description de la scfene : scfcne B1FS, textures. 

Dds que le contenu multimedia devient riche cette repetition simple n'est 
pas acceptable et conduit & des temps de teiechargement excessifs. Par ailleurs, 
cette specification ne permet pas de diffuser certains elements multimedia (clips 
25 audio/video de courte dunee). 

Par ailleurs, dans la demande de brevet non encore publiee EP-01 
4600462, les donnees etaient vehicuiees au niveau du transport. En revanche, 
selon Tinvention, le tout se trouve au niveau de la couche dite de synchronisation 
qui est independante du transport. 
30 Ceci a pour avantage de s'abstraire des differents types de transport et 
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d'unifier les informations de synchronisation temporelle et logiques ainsi que les 
marqueurs d'acc&s aieatoire en un mSme point, ceci permet de calculer h un 
endroit unique la decision de conserver ou pas Punite. D s'avdre que Ton connait 
par ailleurs bien plus d'informations sur le flux, ce qui permet de specialiser les 
5 decisions par type de flux (interessant pour video/audio par rapport & BIFS, etc). 
1 .2 synchronisation multimedia 

L'art anterieur en matifere de synchronisation multimedia est reprdsente 
essentiellement par les protocoles de transport bases sur RTP et par MPEG-4 
(Synchronization Layer). Dans Tapproche utilisee, les m£chanismes de 
10 synchronisation ont 6t6 principalement con?us pour synchroniser temporellement 
un flux audio et un flux video, afin qu'ils soient pr£sent£s sans decalage. Ces 
informations etaient vehicuiees au moyen d*un systeme d'estampillage temporel 
(une horloge de reference, des estampilles de d£codage et de presentation) 

Avec ravfcnement de codages hierarchiques oh de differents niveaux 
15 d'enrichissement temporel et spatial sont utilises afin de produire une trame 
presentable, un nouveau besoin de synchronisation apparait. En effet, il est 
necessaire de synchroniser les flux avant leur d6codage (et non pas seulement h 
leur presentation). Cette contrainte s'av&re plus complexe que la synchronisation 
de presentation car il est necessaire d'identifier quels sont les unites necessaires au 
20 decodage d'une unite afin de produire une trame correcte. Un seul d£calage peut 
rendre inutile tout un flux ainsi que tous les flux bases sur ce demier. Comme on 
le voit, il s'agit d'un probl&me de dependance logique entre unites & decoder. 

Un intervalle de temps reduit est d€fi pris en compte dans MPEG-4 video, 
mais celui-ci n'est pas accessible aux couches systfeme. 
25 1 .3 protection des donnees 

Un troisi&me cas de synchronisation n'est pas aborde dans Tart anterieur : 
celui de la synchronisation d'un flux de protection de donnees lie & un flux 
multimedia. 

Dans ce cas, il est necessaire de s 1 assurer que toute unite de flux 
30 multimedia sera decryptee avec une cie correcte avant d'gtre decodee (le cas 
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€ch6ant les resultats ont toute chances d'etre catastrophiques). D6s lors que les 
flux ne sont pas assures d'etre synchrones, les outils de synchronisation ne 
peu vent assurer ceci. 

Cette fois-ci, F entree du decodeur et la sa sortie sont des points de 
5 synchronisation (la trame decodee peut a son tour etre cryptee). 
2. principes de Pinvention 

Les buts de V invention sont notamment de permettre : 

• La diffusion multicast et broadcast de scenes multimedia ; 

• La synchronisation logique du d£codage multimedia. 

10 Ceci est obtenu & Taide de mgcanismes de signalisation permettant 

d'atteindie ces deux objectifs : 

• M6canisme permettant configurer un flux afin que chacune des 
unites temporelles le composant s'identifient de fa9on 
param£trable. 

15 • M£canisme de chainage avant pour les sc£narii de 

diffusion/broadcast. 
Les elements techniques essentiels de l'invention sont ainsi : 

• Elements de synchronisation logique entre elements de plusieurs 
flux ou dans le meme flux (video, audio, et syst&me de protection 

20 de donn£es) ; 

• La solution permet pour chaque element du flux d'indiquer de quel 
type d 'elements il depend, et de quels elements en particulier il 
depend. Plusieurs mises en oeuvre sont possibles. 

On utilise notamment, sous toute forme de realisation : 
25 • Descripteur de dependance : « DependencyDescriptor » ; 

• Marqueur de dependance : « DependencyMarker » 
(Optionnellement) ; 

• Pointeur sur Tunite dont on depend : « DependencyPointer » ; 

• Marqueur (identifie une unite du flux) : « marker » 
30 (Optionnellement). 
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3. Descriptio n ftetaillee d'au moins un mode particulier de realisation : 

3.1 specification MPEG4 

L'annexe 1 pr6sente de fa$on d6taill6e un exemple de mise en oeuvre de 
Tinvention pour des normes de type MPEG, sous la forme d'une specification 
5 MPEG-4. 

3 2 comportement du rgcepteur 

Le terminal re?oit un IOD (InitialObjectDescriptor) celui-ci fait reference 
par rinterm£diaire de leurs descripteurs (ObjectDescriptor) a au moins un objet 
de description de sc&ne graphique (flux BIFS : F_BIFS) et optionnellement a au 
10 moins un objet de description d'objets graphiques (flux d'OD : F_OD). Le 
terminal va ouvrir ces flux en se basant sur les informations pr6sent6es ci-aprfes. 

Chacun de ces descripteurs d'objet contient un descripteur par flux 
£l£mentaire (ES) qui le compose (ESDescriptor). Chaque ESDescriptor contient 
un champ dependsOnESID et un SLConfigDescriptor. 
15 Le champ dependsOnESID permet de construire le graphe des 

d£pendances entre flux identifies par leur ESID. 

L'objet SLConfigDescriptor permet de configurer les outils de 
synchronisation. 

On trouvera dans Tobjet SLConfigDescriptor la possibility de configurer le 
20 rdcepteur afin qu'il v6rifie les differentes d^pendances de la fa$on suivante : 



DependencyMarker //permet de configurer le 

stream afin qu'il identifie ses paquets. 
{ 

25 int (5) markerLength; 

} 

DependencyDescriptor //permet de d6crire les 

liens de d£pendance. 

{ 

30 int(2) mode; // 0 : mode version par DTS, 
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// 1 :mode version par ID, 
// 2 : mode scalable, 
// 3 : mode IPMP 

// si mode=l la dependance se fait % h un 



5 marqueur dans le stream. 



// si mode=3 la dependance se fait de fagon opaque 
(1© systeme IPMP se doit de 

// comprendre la dependance et de valider ou 
non le d6codage/d€cryptage. 
10 // eventuellement en utilisant un marker. II 

s'agit done d'un code 

// . qui permet au systfcme de protection de 
savoir s*il s'agit ou non d'une 

// unite decryptable (ou non) 
15 // si mode=0 ou mode=2, la dependance est 

calcuiee sur le DTS 

// par consequent depLength = dtsLength dans 
le SLConfig correspondant. 
int(5) depLength; 
20 if (mode=l II mode==0) 

{ 

int(depLength) value; //valeur de la premifere unite & 

chercher. 
} 

25 } 

Ainsi, un flux peut se declarer dependant d'un autre flux (lui-mgme, un 
media normal ou IPMP). Dans ce cas, il d£crit dans sa configuration SL comment 
il va signaler cette dependance (Dependency descriptor) dans quatre modes 
distincts : 

30 32 J Mode version par DTS et par ID (modes 0 et 1) : 
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Le flux va signaler pour chacune de ces AccessUnits (AU)une 
dgpendance avant dans le flux lui-meme. Dans d'autres termes l'AU(n) 
precise quelle est la prochaine AccessUnit a decoder. Cette signalisation se 
fait au moyen d'un marqueur dans chaque paquet qui d6crit ou bien, dans 
5 le mode 0 le DTS de la prochaine Access Unit (unique) ou bien l'ID de la 

prochaine Access Unit dans le mode 1. 

Dans ce cas on rajoute la valeur du premier 616ment a r6cup6rer. 

II peut par exemple s'agir d'un flux BIFS en mode 
broadcast/multicast. 
10 322 Mode scalable {mode 2) : 

Le flux va signaler pour chacune de ces Access Units une 
d6pendance par rapport k un flux dont il depend. Ce flux est suppose 
unique. 

Ce principe est illustrg par la figure 1. L'unit6 de flux 11 d'un flux 
15 dependant 10 comprend classiquement un en-tete (SLHeader) 111 et un 

champ de donn£es (SL payload) 112. L'en-t6te 111 comprend notamment 
deux pointeurs Depl et Dep2, qui ddfinissent des liens de ddpendance 12 
et 13 avec des unites de flux 141 et 142 respectivement d'un flux de base 
14, dont la connaissance est n£cessaire pour traiter l'unit6 de flux 1 1 . 
20 323 Mode IPMP (mode 3) : 

Le flux va signaler pour chacune de ces AccessUnits un 
identificateur qui peimet au systeme de protection de donn£es de decoder 
l'unit6. Celui-ci dtant donn6 ce marqueur peut r^pondre si oui ou non il sait 
d^crypter l'unite. 

25 Le SLConfigDescriptor peut contenir un ou plusieurs 

DependencyDescriptor et un ou plusieurs DependencyMarker, ce qui permet de 
r6gler les differents cas de ddpendance dans le flux. (A priori un seul 
DependencyMarker suffit, mais on peut £ventuellement en avoir plusieurs) 

Ainsi si le SLConfig contient DependencyMarker, il signalera un ID de 

30 version pour chacun de ses paquets (modes 1 et 3). 
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Dans Tentete d'un paquet SL correspondant k une AccessUnit on trouvera 

done : 

• Pour chaque dependencyMarker du SLConfigDescriptor, un 
marker de longueur markerLength. 
5 • Pour chaque DependencyDescriptor un dependencyPointer de 

longueur depLength. 
Une fois ces diffcrents marquages r6alis£s, le sysfeme est k mgme de : 

a) Fonctionner en mode « broadcast » grace aux modes 0 et 1 ; 

b) G6rer les d6pendances de scalability ; 
10 c) G6rer les d£pendances IPMP ; 

et les combinaisons de a),b),c). 

3 .3 Description du fonctionnement en mode IPMP 

Lors de la reception de rObjectDescriptor relatif k un objet, le terminal 
examine le SLConfigDescriptor pour chacun des flux associ6s. Ceci permettra de 
15 decoder TentSte des paquet s SL pour chacun des flux : en particulier de decoder 
les marqueurs. 

Dans le cas IPMP il y aura des DTS et/ou des dependencyPointer, ainsi 
que cela est illustrd en figure 3. 

Pour chaque AU du flux, avant que celui-ci ne soit d€cod6, il est trait£ par 
20 le systfcme IPMP 32, en lui fournissant au moins les donndes suivantes identifiant 
de flux ESID, DTS, dependencyPointer (IPM) 31 . Le systfcme IPMP nJpond alors 
(33) s'il est en mesure de traiter (d^crypter) TAU, en consid^rant reformation 
311 (Code Dec) relative au d^codage. Si ce n'est pas le cas et que le DTS de 
Tunit6 est arriv6 k maturity, TAU est d£truite (34). On n'essaie done pas de 
25 decoder des AU non coh6rentes. 

Dans Texemple de la figure 4, on retrouve d'une part les 616ments de la 
figure 3, et d'autre part un traitement U6 k la restitution de Timage, apr&s son 
d£codage 41. En effet, k Taide du champ 312 (CodeComp), on peut transmettre 
des donn€es relatives k la composition, tel que Tajout d'un tatouage ou d'un 
30 message sur Fimage. Si le sysfeme de protection de donn^es 32 ne sait pas g£rer 
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cette composition (il ne sait pas afficher Fimage (42)), par exemple parce que le 
dgcodeur ne dispose par du tatouage requis, Fimage n'est pas afficltee (43)* 

On peut <5galement pr6voir que la trame sera marquee par exemple d'un 
logo, qui disparait si le d6codeur dispose de la bonne cte. 
5 3.4 Description du fonctionnement en mode multicast/broadcast . 
Ce fonctionnement est illustr6 en figure 2, qui pr^sente : 
le flux dmis 21 ; 

le flux re$vt par un premier r6cepteur (session 1) 22 ; 

le flux re9u par un premier r6cepteur (session 2) 23. 
10 La session 1 d^marre sur le paquet 211, puis prend en compte Funite de 

flux 213, sur lequel pointe (24) Funite de flux 21 1, puis Funite de flux 215, selon 
le lien 25. 

La session 2, entantee teg&rement apr&s, d^marre avec Funite de flux 212, 
qui pointe (26) sur Funite de flux 214. 
15 Selon Finvention, deux (ou plus) unites de flux peuvent pointer sur une 

meme unite de flux suivante. C'est le ntecanisme de fusion 27 : les unites de flux 
213 et 214 pointent toutes deux sur Funite de flux 215. Ainsi, bien qu'ayant 
d£butees k des instants difterents, les deux sessions utilisent, aprfes une phase « de 
rattrapage, les memes unites de flux 215. Cela permet clairement d'anteliorer le 
20 rendement. 

On d£crit plus pr€cis6ment ce fonctionnement. 

Lors de la reception de FObjectDescriptor, le terminal examine le 
SLConfigDescriptor pour chacun des flux assoctes. Ceci permettra de decoder 
l'entete des paquets SL pour chacun des flux : en particulier de decoder les 
25 marqueurs. 

Dans le cas Multicast/Broadcast il y aura des done des DTS, au moins un 
dependencyPointer en mode 0 ou 1 , et un marqueur (mode 1 « par ID ») . Le 
terminal sait done quelle est la premiere unite & r£cup6rer pour chacun des flux. II 
essaiera done de r£cup6rer la premifere unite correspondant k chaque flux. 
30 S*il re9oit la premifere unite, alors il peut commencer £ afficher le contenu. 
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Chaque unit6 dgcrit dans le « dependencyPointer » la prochaine unit6 & recevoir et 
le DTS/marqueur identifie chaque unit6 de fagon unique. 

Si le terminal ne regoit pas la premiere unitg (il peut s'en rendre compte ou 
bien par time-out ou dbs qu'il re$oit une unite pour ce flux de type RAP=1 qui ne 
5 correspond pas au marqueur souhait6). II se d€connecte (fermeture complete de 
session) et essaie de se reconnected 

On notera que ce m6canisme prend en compte la fusion de sessions. 
On notera 6galement que le mode par ID est n6cessaire dbs que Ton ne sait 
pas h Favance le DTS de la prochaine unite. 
10 Ce m£canisme est utilise notamment pour BIFS,OD /Textures, clips audio, 

clips vid6o dans MPEG-4. Pour la vid€o/audio streamee il ne sera pas utilise. 
3 5 Description du fonctionnement en mode scalable 

Lors de la reception de TObjectDescriptor, le terminal examine le 
SLConfigDescriptor pour chacun des flux assoctes. Ceci permettra de decoder 
15 TentSte des paquets SL pour chacun des flux . Pour de la vid6o scalable, un flux 
servira de base et un ou plusieurs autres flux dgpendront de celui-ci. Chaque flux 
dependant du flux de base d€clarera un DependencyDescriptor. 

Pour chaque AU du flux d'am61ioration, il r£f6rencera grSce au 
dependencyPointer les DTS des AU du flux de base dont il depend. 
20 Dans la plupart des cas, il y aura deux dependencyPointer dans le flux 

d'am&ioration afin de pointer sur les deux AU de reference de la vid6o de base. 
3.6 Description du fonctionnement en mode broadcast+EPMP 

Dans ce cas, le BIFS, par exemple contiendra deux dependencyDescriptor 
dans la configuration SL. I/un pour le mode broadcast, Tun pour IPMP. II 
25 contiendra un marqueur si le mode broadcast est par ID. 
4. Exemoles d 'applications : 

4.1 Diffusion d'une publicit6 avant de commencer un programme 

Dans de nombreux cas de streaming sur Internet, les fournisseurs de 
contenu envoient syst&natiquement une publicity avant d'envoyer le contenu lui- 
30 mSme. Les sc6narii internet 6tant unicast (client-serveur), cela se fait en deux 
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phases : teiechargement de la publicity, la fin de la publicity d6clenche le 
lancement du streaming de la video. 

Dans un scenario multicast ou broadcast, oil Ton ne peut avoir recours & un 
fonctionnement client-serveur, il n'y a pas de notion de requSte, de ce fait, 
5 Tutilisateur n'a g^n^ralement accfcs qa*h T6tat courant de la presentation. 

Grace au m^canisme de reference avant ce scenario devient possible en 
multicast ou bien en broadcast. 

En effet, il est possible d'envoyer de fa$on cyclique la publicity et de 
fusionner vers le programme en cours en fin de publicity. 
10 Ceci permet de s 'assurer par exemple que tout utilisateur visualisera la 

publicity au debut (Pendant ce temps te, on peut r6aliser le teiechargement du 
contenu pour la suite de fagon efficace et incremental). 

Des applications du meme type peuvent etre, pour chaque film diffuse, une 
notification de la categorie du film (accord parental, moins de 16 ans, etc. . .). 
15 42 Accfes conditionnel scalable 

L'id6e ici est d'envoyer le meme flux (unique) video et audio pouvant 6tre 
visualise de fa$on diff6rente en fonction des droits des utilisateurs. La 
signalisation des d£pendances des trames video par rapport aux cies de protection 
permet de decoder uniquement celles dont on a la cie. On peut done decoder 
20 toutes les images pour celui qui possfede toutes les cies, des images pour un 
utilisateur ayant moins de droits, etc... Ceci permet de faire de Tacc&s 
conditionnel de fa?on plus echelonnable.(echelonnelabilite temporelle ici) 

Le scenario, plus complexe, et plus utile est celui oii Ton a plusieurs flux 
et oh Ton peut jouer & la fois sur rechelonnabilite temporelle et en resolution 
25 Avec ce systfeme de dependance par trame, il est done possible de moduler 

de fagon quasi-continue l'accfes aux medias. 

On peut done imaginer que certains utilisateurs auraient des cies 
permettant de recevoir le son sur 5 voies (son spatialise) et d'autres uniquement le 
son stereo. Ce qui permettrait egalement une facturation plus fine. . . 
30 4.3 Television Interactive MPEG-4 
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Au lieu de considgrer que l'applicatif de la « set-top box » est statique, on 
peut consid€rer que tout cet applicatif est une application MPEG-4 qui permet 
d'atteindre les diff6rentes chaines (m^canisme d'inline). Cette application MPEG- 
4 serait active 24h/24h et permettrait de reconfigurer compl&tement les interfaces 
5 graphiques.etc... 

La technique de diffusion de scene permettrait de t616charger efficacement 
Tinterface graphique (BIFS/Textures/OD) ainsi que la partie applicative (MPEG- 
J). 

Ceci permet un d6ploiernent/red6ploiement rapide. 
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ANNEXE 

EXEMPLE DE SPECIFICATION DE TYPE MPEG-4 
SELON L'INVENTION 

5 1- Definitions 

1 .1 Unite de flux f AU : Access Unirt 

Une unite de donn6es accessible individuellement dans un flux eiementaire 
(elementary stream). Une unite de flux (ou unite d*acc£s) est la plus petite entite & 
laquelle une information temporelle peut etre attribute. 
10 1 .2 Objet Audiovisuel 

Une representation d'un objet naturel ou synthetise (virtuel) qui se 
manifeste de fa?on auditive et/ou visuelle. La representation correspond h un 
noeud ou k un groupe de noeuds dans la description de la sequence BIFS. Chaque 
objet audiovisuel est associe k zero, un ou plusieurs flux eiementaires (elementary 
15 streams) utilisant un ou plusieurs descripteurs d f objet (object descriptors). 
1 .3 Sequence Audiovisuelle (AV Scene) 

Une s£rie d'objets audiovisuels avec des informations d6crivant la scfene 
qui definissent leurs attributs spatiaux et temporels incluant les fonctionnements 
resultant de Tobjet et des interactions de Tusager. 
20 1 .4 Format Binaire de Scfene (BIFS^ 

Une representation codee d'un format de description de scene 
parametrique. 
1 .5 Terminal 

Un systeme qui envoie ou re?oit et presente la representation codee d'une 
25 scfene audiovisuelle interactive comme definit par ISO/IEC 14496-1. Cela peut 
etre un systfeme autonome ou partie d'un systfcme d'application se soumettant & 
ISO/IEC 14496. 

2. Abreviations et svmboles 



AU 



Unite d* Accfcs, ou Unite de Flux (Access Unit) 
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AV 


Audiovisuel (Audio-visual) 


BIFS 


Format Binaire de Scene (Binary Format for Scene) 


CM 


Memoire de Composition (Composition Memory) 


CTS 


Estampille Temporelle de Composition (Composition Time Stamp) 


CU 


Unite" de Composition (Composition Unit) 


DAI 


Interface d' Application DMIF (voir ISO/IEC 14496-6) (DMIF Application Interface) 


DB 


Memoire Tampon de Decodage (Decoding Buffer) 


DTS 


Estampille Temporelle de Decodage (Decoding Time Stamp) 


ES 


Flux Elementaire (Elementary Stream) 


ESI 


Interface de Flux Elementaire (Elementary Stream Interface) 


ESID 


Identifiant de Flux Elementaire (Elementary Stream Identifier) 


FAP 


Parametres d'Animation Faciale (Facial Animation Parameters) 


FAPU 


Unites FAP (FAP Units) 


NCT 


Tables de Codage de Noeuds (Node Coding Tables) 


NDT 


Noeud de Donnee Type (Node Data Type) 


OCI 


Informations sur le Contenu de l'Objet (Object Content Information) 


OCR 


Reference d'Horloge Objet (Object Clock Reference) 


OD 


Descripteur d'Objet (Object Descriptor) 


ODID 


Identifiant de Descripteur d'Objet (Object Descriptor Identifier) 


OTB 


Base de Temps Objet (Object Time Base) 


PLL 


Boucle a Verrouillage de Phase (Phase Locked Loop) 


QoS 


Quality de Service (Quality of Service) 


SDM 


Modele de Decodeur de Systeme (System Decoder Model) 


SL 


Couche de Synchronisation (Synchronization Layer) 


SL-Packet 


Paquet de la Couche de Synchronisation (Synchronization Layer Packet) 


SPS 


Flux de SL-Packets (SL-Packetized Stream) 


STB 


Base de Temps Systeme (System Time Base) 


TTS 


Texte vers Parole (Text-To-Speech) 


URL 


Localisateur de Ressources Universelles (Universal Resource Locator) 


VOP 


Plan d'objets video (Video Object Plane) 
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VRML Langage de Mod61isation de R6alit6 Virtuelle (Virtual Reality Modeling Language) 



3, Configuration d'en tete de oaauet SL 

3.1 Svntaxe 

5 class SLConf igDescriptor extends BaseDescriptor : bit (8) 
tag^SLConf igDescrTag { 
bit (8) predefined; 
if (predef ined=0) { 

bit(l) useAccessUnitStartFlag; 
10 bit(l) useAccessUnitEndFlag; 

bit(l) useRandomAccessPointFlag; 
bit (1) hasRandomAccessUnitsOnlyFlag; 
bit (1) usePaddingFlag; 
bit (1) useTimeStampsFlag; 
15 bit(l) useldleFlag; 

bit(l) durationFlag; 

bit ( 32 ) timeStampResolution ; 

bit (32) OCRResolution; 

bit (8) timeStampLength; // must be * 64 
20 bit (8) OCRLength; // must be as 64 

bit (8) AU_Length; // must be as 32 

bit (8) instantBitrateLength; 

bit (4) degradatidnPriorityLength; 

bit (5) AU_seqNumLength; // must be * 16 
25 bit (5) packetSeqNumLength; // must be ss 16 

bit (2) extension field control; 



} 

30 if (durationFlag) { 

bit (32) timeScale; 

bit (16) accessUnitDuration; 

bit (16) compositionUnitDuration; 

} 

35 if (! useTimeStampsFlag) { 

bit (timeStampLength) startDecodingTimeStamp; 
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bit (timeStampLength) startCompositionTimeStamp; 

) 

if (hasNextAU) { 

bit (timeStampLength) nextDecodingTimeStamp; 

5 ) 

if (extension_f ield_control==0bl0) 
{ 

MarkerDescriptor [0..1] markerDescriptors; 
DependencyDescriptor [0..255] dependencyDescriptors; 

10 ) 

dependencyMarkersCount=0; 

while (true) 
{ 

15 bit(l) hasMoreMarkers ; 

if (IhasMoreMarkers) break; 

DependencyMarker dependencyMarkers [dependencyMarkers Count ++] ; 

20 } 

dependencyDescriptorCount =0 ; 

while (true) 
{ 

25 bit(l) hasMoreDependencyDescriptor; 

if (! hasMoreDependencyDescriptor) break; 

DependencyDescriptor dependencyDe scrip tor 
[dependencyDescriptorCount++] ; 

30 > 
) 

32. S6mantique 

L*entete de paquet SL peut 6tre configure selon les besoins de chaque flux 
£16mentaire individuel. Les param&tres qui peuvent 6tre s^lectionn^s comprennent 
35 la presence, la resolution et la precision des estampilles temporelles et des 
references d'horloge. Cette flexibility permet, par exemple, une faible 
augmentation du contenu de Tentete de paquet SL. 

Pour chaque flux 616mentaire, la configuration est transmise dans un 
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SLConf igDescriptor, qui fait partie du ES_Descriptor assocte & un 
descripteur d'objet. 

Les paramfetres configurables dans TentSte de paquet SL peuvent Stre 
divis£s en deux classes : ceux qui s'appliquent & chaque paquet SL (par exemple 
5 OCR, sequenceNumber) et ceux qui sont strictement apparent£s aux unites 
d'accfcs (par exemple : estampilles temporelles, accessUnitLength, instantBitrate, 
degradationPriority ) . 

La colonne - predefined - permet de fixer par d^faut les valeurs 
d*un ensemble de paramfetres pr£d£finis comme d£taill£ ci-dessous. Ce tableau 
10 pourra etre mis & jour par amendements a ISO/IEC 14496 pour inclure les 
configurations pr6d6finies comme exig6 par les futurs profils. 



Tableau 1 - Vue d'ensemble des valeurs SLConf igDescriptor 

pr£d6finies 



Champ de valeur 
pr£d£fini 


Description 


0x00 


Clientele (custom) 


0x01 


Entete de paquet SL nulle 


0x02 


R6serv6 h Tusage dans les fichiers MP4 


0x03 - OxFF 


R6serv6 & Tusage ISO 



Tableau 2 - Detail des valeurs SLConfigDescriptor pr£d£finies 



Champ de valeur predeiini 


0x01 


0x02 


UseAcces sUnitStartFlag 


0 


0 


UseAccessUnitEndFlag 


0 


0 


UseRandomAccessPointFlag 


0 


0 


UsePaddingFlag 


0 


0 


UseTimeStampsFlag 


0 


1 


UseldleFlag 


0 


0 
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DurationFlag 


0 


0 


TimeStampResolution 


1000 


- 


OCRResolution 


- 


- 


TimeStampLength 


32 


0 


OCRlength 




0 


AU_length 


0 


0 


InstantBitrateLength 




0 


DegradationPriorityLength 


0 


0 


AU_seqNumLength 


0 


0 


PacketSeqNumLength 


0 


0 




Champ de valeur pr£d£fini 


0x01 


0x02 


UseAccessUnitStartFlag 


0 


0 


UseAccessUnitEndFlag 


0 


0 


UseRandomAcce ssPointFlag 


0 


0 


UsePaddingFlag 


0 


0 


UseTimeS tamps Flag 


0 


1 


UseldleFlag 


0 


0 


DurationFlag 




0 


TimeStampResolution 


1000 




OCRResolution 






TimeStampLength 


32 


0 


OCRlength 




0 


AU_length 


0 


0 


InstantBitrateLength 




0 


DegradationPriorityLength 


0 


0 


AU_seqNumLength 


0 


0 


PacketSeqNumLength 


0 


0 
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25 



TimeScale 






AccessUnitDuration 






CompositionUnitDuration 






StartDecodingTime Stamp 






S t a r tComposi t ionTimeS tamp 







useAccessUnitStartFlag - indique que le 
accessUnitStartFlag est present dans chaque entete de paquet SL de ce 
flux 616mentaire. 

5 useAccessUnitEndFlag - indique que le accessUnitEndFlag 

est present dans chaque entete de paquet SL de ce flux 616mentaire. 

Si ni useAccessUnitStartFlag ni useAccessUnitEndFlag 
ne sont actifs, cela implique que chaque paquet SL correspond & une unit6 d'accfes 
complete. 

10 useRandomAccessPointFlag - indique que le 

RandomAccessPointFlag est present dans chaque entSte de paquet SL de 
ce flux £16mentaire. 

hasRandomAccessUnitsOnlyFlag - indique que chaque paquet 
SL correspond k un point d'accfcs algatoire. Dans ce cas, le 
15 randomAccessPointFlag n'a pas besoin d'6tre utilis6. 

usePaddingFlag - indique que le paddingFlag est present dans 
chaque entete de paquet SL de ce flux 61£mentaire. 

useTimeStampsFlag - indique que les estampilles temporelles sont 
utilises pour la synchronisation de ce flux dl£mentaire. Elles sont transports 
20 dans les entete de paquet SL. Sinon, les param&tres accessUnitRate, 
compositionUnitRate, StartDecodingTimeStamp et 
startCompositionTimeStamp transports dans cet entete de paquet SL 
doivent etre utilises pour la synchronisation. 

L'utilisation d'estampilles temporelles de depart et de dur6e 
25 (useTimeStampsFlag=0) est faisable uniquement sous certaines conditions, 
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incluant un environnement sans erreur. L'acc&s al6atoire n'est pas ais€. 

useldleFlag - indique que idleFlag est utilise dans ce flux 
61£mentaire. 

durationFlag - indique que la dur6e constante des unites d'accfcs et 
5 des unites de composition pour ce flux 61£mentaire est signatee ult6rieurement. 

timeStampRe solution - est la resolution des estampilles temporelles 
en impulsions par seconde. 

OCRResolution - est la resolution de la base temporelle de Tobjet en 
cycles par seconde. 

10 t imeS tampLength - est la longueur des champs d'estampille 

temporelle dans les entSte de paquet SL. times tampLength doit prendre des 

valeurs entire z6ro et 64 bits. 

OCRlength - est la longueur du champ ob j ectClockRef erence 

dans TentSte de paquet SL. Une suite de z£ros indique qu'aucun 
15 obj ectClockRef erences n'est present dans ce flux 61€rnentaire. Si 

OCRstreamFlag est mis, OCRLength doit Stre z6ro. Sinon, OCRlength 

doit prendre des valeurs entre z6ro et 64 bits. 

AU_ Length - est la longueur des champs accessUnitLength dans 

Tent6te de paquet SL pour ce flux £16mentaire. AU_Length doit prendre une 
20 valeur entre z6ro et 32 bits. 

instantBitrateLength - est la longueur du champ 

instantBitrate dans Tentete de parquet SL pour ce flux 616mentaire. 

degrada tionPr ior i tyLength - est la longueur du champ 

degradationPriority dans Tentgte de paquet SL pour ce flux 616mentaire. 
25 AU_seqNumLength - est la longueur du champ 

AU_sequenceNumber dans TentSte de paquet SL pour ce flux 616mentaire. 

packetSeqNumLength - est la longueur du champ 

packetSequenceNumber dans Tentete de paquet SL pour ce flux 

61£mentaire. 

30 timeScale - est utilise pour exprim6 la dur6e des unites d'accfcs et des 
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unites de composition. Une seconde est 6galement divisde en parties 
timeScale. 

accessUnitDuration - la dur6e d'une unit6 d'accfcs est 
accessUnitDuration * 1/timeScale secondes. 
5 compos itionUnit Duration - la dur6e d'une unit€ de composition 

est compositionUnitDuration * 1/timeScale secondes. 

startDecodingTimeStamp - transporte le temps auquel la premifcre 
unitS d'accfcs de ce flux 616mentaire doit etre decode. II est transport^ dans la 
resolution sp£cifi6e par timeStampRe solution. 
10 startCompositionTimeStamp - transporte le temps auquel i*unit6 

de composition correspondant k la premifere unit6 d'accds de ce flux 616mentaire 
doit etre d6cod6. II est transport^ dans la resolution sp6cifi6e par 
timeStampResolution. 

extension^ ield_control - Ce champs permet d'6tendre le SL. 
15 La valeur OlbO indique que les descripteurs doivent se trouver k la fin du 
SLConfigDescriptor. 

markerDescriptors - Cette table indique une description de 
marqueurs pour identifier les unites d'accfes suivantes dans le flux 

dependencyDescriptors - Cette table indique les descripteurs de 
20 d£pendance sp£cifiant comment r6f6rencer soit les unites d'accfes pr6c6dentes soit 
les unites £ venir. 
4. MarkerDescrintor 

La syntaxe est la suivante : 

25 class MarkerDescriptor extends BaseDescriptor : bit (8) 
tag=DependencyMarkerTag { 

int(5) encodedMarkerLength; 
MarkerLength« encodedMarkerLength + 1; 

) 

30 

5 r DependencvDescriptor 



5 1 svntaxe 
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abstract class DependencyDescriptor extends Base Descriptor { 
) ; 

class SimpleDependencyDe scrip tor extends BaseDescriptor : bit (8) 
5 tag^SimpleDependencyTag { 
bit (2) mode; 

bit (5) dependencyLength; 
if (mode==l | I mode==0) 
{ 

10 bit (dependencyLength) firstvalue; 

> 

) ; 

class Connie teDependencyDe script or extends BaseDescriptor : bit (8) 
15 tag=CompleteDependencyTag { 
bit (2) mode; 
bit (16) ESID ; 
bit (5) dependencyLength; 
if (mode==l | | mode==0) 

20 { 

int (dependencyLength) firstvalue; 

) 

) ; 

25 5.2 s6mantique 
52 J mode 

Quatre modes sont ddfinis : 

• Mode 0 : reference vers Tavant par DTS. 

• Mode 1 : reference vers 1'avant par Marqueur. 
30 • Mode 2 : reference arrifcre de scalability. 

• Mode 3 : mode IPMP. 

Les modes 0 et 1 forcent chaque unite d'acc&s h faire reference k la 
prochaine unite d'acc&s. 

Le mode 2 force chaque unite d'accfcs & faire reference & l'unite d*accfcs 
35 pr6c€dente qui est n6cessaire pour decoder cette unite d'accfes. (Note : Dans de 
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nombreux cas, plus de deux dependencydescriptors sont n£cessaires, pour 
se r6f€rer & deux unites d'accfes n^cessaires ou plus). 

Le mode 3 permet h chaque unitd d'accfes de contenir un identifiant 
opaque, qui peut etre utilise par le systfcme IPMP, afin de decider si le d€codage 
5 et la composition de cette unite d'acc&s est possible. 

Les modes 1 et 3 requterent un Marker Descriptor dans le flux. 
522 ES1D 

Ce champ optionnel identifie le flux auquel le DependencyDescriptor fait 
reference. 

10 Pour SimpleDependency Descriptor, ESID est calcul6 de la manifcre 

suivante : 

• Modes 0 et 1 : le flux courant. 

• Mode 2 : selon dependsOnESID 

• Mode 3 : pas applicable. 

15 dependencyLength - est la longueur, soit du marqueur (si il existe) soit 

du decodingTimeStamp. 

value - est la valeur du premier marqueur ou dts identifiant la prochaine 
unit6 d'acc&s & decoder 

6. Specification de Fentete de oaouet SL 

20 6.1 Svntaxe 

aligned (8) class SL_Packet Header (SLConf igDescriptor SL) { 
if (SL.useAccessUnitStartFlag) 
bit (1) accessUnitStartFlag; 
if (SL.useAccessUnitEndFlag) 
25 bit(l) accessUnitEndFlag; 

if (SL.OCRLength>0) 

bit(l) OCRflag; 
if (SL.useldleFlag) 
bit(l) idleFlag; 
30 if (SL.usePaddingFlag) 

bit(l) paddingFlag; 
if (paddingFlag) 

bit (3) paddingBits; 
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if (lidleFlag && ( IpaddingFlag II paddingBits !=0) ) { 
if (SL.packetSeqNumLength>0) 

bit {SL . packetSeqNumLength) packetSequenceNumber ; 
5 if (SL.degradationPriorityLength>0) 

bit (1) DegPriof lag; 
if (DegPriof lag) 

bit (SL.degradationPriorityLength) degradationPriority; 
if (OCRflag) 

10 bit (SL.OCRLength) objectClockReference; 

if (accessUnitStartFlag) { 

if (SL.useRandomAccessPointFlag) 
bit(l) randomAccess Point Flag; 
15 if (SL.AU_seqNumLength >0) 

bit (SL. AU_seqNumLength) AU_sequenceNumber ; 
if (SL.useTimeStampsFlag) { 

bit(l) decodingTimeStampFlag; 
bit(l) compos itionTimeStampFlag; 

20 } 

if (SL,instantBitrateLength>0) 

bit (1) instantBitrateFlag; 
if (decodingTimeStampFlag) 

bit (SL. timeS tampLength) decodingTimeStamp; 
25 if (compositionTimeStampFlag) 

bit (SL. times tampLength) compositionTimeStamp; 
if (SL.AU_Length > 0) 

bit (SL. AU_Length) accessUnitLength; 
if (instantBitrateFlag) 
30 bit (SL. instantBitrateLength) instantBitrate; 

) 

) 

if (SL.hasMarker && beginningOf AU () ) 
{ 

35 for (int 1=0; K markerDescriptorCount; I++) 

{ 

bit (marker . length) markerValue 
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} 

} 

for (int 1=0; I< dependencyDescriptorCount; I++) 
{ 

5 if (dependencyDescriptor .mode»l == 0) 

{ 

bit (dependencyDe scrip tori I] .depLength) depondencyPoin te rvalue; 

> 

) 

10 > 

62 Semantique 

accessUnitStartFlag - quand il vaut un, indique que le premier 
octet de la charge de ce parquet SL est le depart d'une unite d'accfes. Si cet 
15 element de syntaxe est omis de la configuration de TentSte de paquet SL, sa 
valeur par defaut est connue du paquet SL precedent suivant la rfcgle suivante : 

accessUnitStartFlag = (le paquet SL precedent a 
accessUnitEndFlag=l) ? 1 : 0. 

accessUnitEndFlag - quand il vaut un, indique que le dernier octet 
20 de la charge du paquet SL est le dernier octet de Tunit6 d'accfcs en cours. Si cet 
element de syntaxe est omis de la configuration de 1'entSte de paquet SL, sa 
valeur par defaut est uniquement connue aprfcs reception du paquet SL suivant la 
rfcgle suivante : 

accessUnitEndFlag = (le paquet SL suivant a 
25 accessUnitStartFlag=l) ? 1 : 0. 

Si ni AccessUnitStartFlag ni AccessUnitEndFlag ne sont 
configures dans 1'entSte de paquet SL, cela implique que chaque paquet SL 
correspond k une seule unite d'accfes, d*ou chaque accessUnitStartFlag = 
accessUnitEndFlag = 1. 
30 On notera, quand Tentete de paquet SL est configure pour utiliser 

accessUnitStartFlag mais ni accessUnitEndFlag ni 
accessUnitLength, il n'est pas garanti que le terminal puisse determiner la 
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fin d'une unit6 d'accfcs avant que la suivant ait 6t6 re^ue. 

OCRf lag - quand il vautun, indique qu'un ob jectClockRef erence 
va suivre. La valeur par d€faut pour OCRf 1 ag est z6ro. 

idleFlag - indique que ce flux 61€mentaire sera inactif (c'est-sl-dire 
5 absence de donn6es utiles) pour un laps de temps ind6termin6. Ce signe peut etre 
utilise par le d6codeur pour faire la distinction entre une absence d61ib£r6e et une 
absence due k une eneur de paquets SL suivants. 

paddingFlag - indique la presence de remplissage dans ce paquet SL. 
La valeur par d£faut pour paddingFlag est z6ro. 
10 paddingBits - indique le mode de donn£es de remplissage & utiliser 

dans ce paquet SL. La valeur par d^faut pour paddingBits est z6ro. 

Si paddingFlag est mis et paddingBits vaut z6ro, cela indique 
que la charge suivante de ce paquet SL consiste uniquement en octets de 
remplissage. accessUnitStartFlag, randomAccessPointFlag et 
15 OCRf lag ne doivent pas §tre mis si paddingFlag est mis et paddingBits est 
zdro. 

Si paddingFlag est mis et paddingBits est sup&ieur k z€ro, cela 
indique que la charge de ce paquet SL est suivie par des paddingBits, form6s 
de bits k z6ro pour Talignement des octets de la charge. 

20 packetSequenceNumber - s'il est present, il doit etre augment^ 

continuellement pour chaque parquet SL comme un compteur modulo. Une 
discontinuity au d6codeur correspond h un ou plusieurs paquets SL manquants. 
Dans ce cas, une erreur doit Stre signalde k la couche de synchronisation. Si cet 
616ment de syntaxe est omis de la configuration de Fentgte de paquet SL f le 

25 contrdle de la continuity des unites de flux par la couche de synchronisation ne 
peut pas gtre accomplie pour ce flux 616mentaire. 

Duplication des paquets SL : les flux 616mentaires qui ont un champ 
sequenceNumber dans leurs ent€tes de paquet SL doivent utiliser la 
duplication des paquets SL pour la recuperation des erreurs. Le(s) paquet(s) SL 

30 dupliqugs doivent imm6diatement suivre r original. Le packet 
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SequenceNumber des paquets SL dupliqu£s doit avoir la meme valeur et 
chaque octet du paquet SL original doit etre dupliqug, k Texception d'un champ 
ob j ectClockRef erence, si present, qui doit encoder une valeur valide pour 
le paquet SL dupliqu£. 
5 degPrioFlag - quand il vaut un, indique que 

degradationPrior ity est present dans ce paquet. 

degradationPriority - indique Timportance de la charge de ce 
paquet SL. Le streamPriority dSfinit la priority de base d'un ES. 
degradationPriority d^finit une baisse de priority pour ce paquet SL par 
10 rapport k la priority de base. La priorit6 pour ce paquet SL est donn6e par : 

SL_PacketPriority = streamPriority - degradationPriority 
degradationPriority reste k cette valeur jusqu'^ la prochaine 
occurrence. Cette indication peut etre utilis^e par le d6codeur du flux 6iementaire 
ainsi que par Tadaptateur pour une instance d'une couche de distribution 
15 sp6cifique. La proportion de la degradation parmi les paquets SL de diffdrents 
flux 616mentaires augmente au fur et k mesure que SL_PacketPriority diminue. 

obj ectClockRef erence - contient une estampilie temporelle objet. 
La valeur temporelle OTB t est reconstruite k partir de cette estampilie temporelle 
OCR selon la formule suivante: 
20 t ss (obj ectClockRef erence/SL .OCRResolution) + 

k * (2 SL.OCRLength /SL 0CRResolution) 

oil k est le temps que le compteur obj ectClockRef erence a couvert. 

obj ectClockRef erence est seulement present dans Tentete de 
paquet SL si OCRf lag est mis. 
25 II est possible de transporter uniquement une valeur OCR sans charge k 

Tint&ieur d'un paquet SL. 

La suite prdsente la sdmantique des 616ments de syntaxe qui sont 
seulement presents au d£but d'une unite d'accfes quand signals explicitement par 
accessUnitStartFlag dans le flux binaire : 
30 randomAccessPointFlag - quand il vaut un, indique que Taccfes 
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al6atoire au contenu de ce flux 616mentaire est possible. 
randomAccessPointFlag doit uniquement 6tre mis si 
accessUnitStartFlag est mis. Si cet 616ment de syntaxe est omis de la 
configuration de TentSte de paquet SL, sa valeur par ddfaut est la valeur de 
5 SLConf igDescriptor . hasRandomAccessUnitsOnlyFlag pour ce 
flux 616mentaire. 

AU_sequenceNumber - si present, il doit 6tre augment^ 
continuellement pour chaque unity d'accds comme un compteur modulo. Une 
discontinuity au d6codeur correspond k une ou plusieurs unites d'accfcs 
10 manquantes. Dans ce cas, une erreur doit etre signage k Tutilisateur de la couche 
synchronisation. Si cet 616ment de syntaxe est omis de la configuration de Tentgte 
de paquet SL, le contrdle de la continuity des unites de flux par la couche 
synchronisation ne peut pas etre exdcutg pour ce flux dldmentaire. 

Duplication des unites d'acces : les unites d'acc&s envoy^es utilisant le 
15 mSme nombre de sequences que FAU imm^diatement pr6c6dente doivent etre 
ignores. Une telle unity d'accds dupliqu6e, dont Toriginal n'avait pas RAP mis, 
mais Tunit6 dupliquye oui, permet Tajout de points d'accfcs aiyatoire dans un flux 
ymis, permettant k des clients d'entrer dans le flux k des points dyfinis, pendant sa 
transmission, pendant que d'autres clients re?oivent d€]k le flux. 
20 decodingTimeStampFlag - indique qu'une estampille temporelle de 

dycodage est prysente dans ce paquet. 

compos itionTimeStampFlag - indique qu'une composition 
d'estampille temporelle est prysente dans ce paquet. 

accessUnitLengthFlag - indique que la longueur de cette unity 
25 d'accfcs est prysente dans ce paquet. 

instantBitrateFlag - indique qu'un instantBitrate est 
prysent dans ce paquet. 

decodingTimeStamp - est une estampille temporelle de dycodage 
comme configury dans le SLConf igDescriptor associe. Le temps de 
30 dycodage td de cette unity d'acc&s est reconstruit k partir de cette estampille 
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temporelle de d6codage selon la formule : 

td = (decodingTimeStamp/SL.timeStampResolution + k* 
2SL.timestampLengi:h /SL ^ t imeS tampResolut ion 
oh k est le temps que le compteur decodingTimeStamp a englob6. 

5 Un decodingTimeStamp doit uniquement Stre present si le temps 

d^codeur est different de la composition temporelle pour cette unite d'acc&s. 
compositionTimeStamp - est une composition d'estampille temporelle 
comme configure dans le SLConf igDescriptor associe- La 
composition temporelle tc de la premifere unit6 de composition nSsulte du fait que 

10 cette unit6 d'accfcs est reconstruite & partir de cette composition d'estampille 

temporelle selon la formule : 

td= (compositionTimeStamp/SL. timeStampResolution + 

k * 2 SL - timeStain P Len 9 th /SL. timeStampResolution 

oil k est le temps que le compteur compositionTimeStamp a englob6. 

15 accessUnitLength - est la longueur de 1'unitd d'accfes en octets. Si 

cet Anient de syntaxe n'est pas present ou a la valeur z<Jro, la longueur de l'unit6 

d'accfcs est inconnue. 

instantBitrate - est le taux binaire instantan6 en bits par seconde de 
ce flux 616mentaire jusqu^ ce que le prochain champ instantBitrate soit 
20 trouv6. 

ma rke rvalue - est la valeur d'un marqueur qui permet d'identifier 
Tunit6 d'accfes . Ce marqueur est ddfini si markerDescr iptors existe. 

DependencyPointerValue - est un indice de DTS ou d'un marqueur 
comme d6finit par le DependencyDescriptor. 
25 MarkerDescriptorCount : le nombre de descripteurs de marqueurs. 

DependencyDescriptorCount : le nombre de descripteurs 
dependants. 

7 t sdmantique de d6codage 

71 M6canisme de reference avant (modes 0 et X) 
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Le SLConf igDescriptor associe k un ES, indique la premiere unite 
d'accfcs qui permet d'entrer dans le flux. 

Si le mode de reference est DTS, alors le SLConfigDescriptor doit contenir 
un decodingTimeStamp. 
5 Sinon, un marqueur est utilise pour marquer chaque unite d'accfcs. 0 et -1 

ont une signification sp6ciale : 

// 0 signifie qu'aucune autre unite d'acc&s suivra, 
//-lsignifie que n'importe quelle unite d'acc&s peut etre utilisee. 
Chaque unite d'accfes doit contenir un marqueur et un dependencypointer 
10 permettant & chaque unite d'acc&s d*indiquer la prochaine unite d'accfcs. 

7 .2 Mecanisme de referenc e arrifere (mode 2) 

Le SLConfigDescriptor definira n descripteurs de type 
DependencyDescriptor, qui indiqueront les unites d'acc&s dans TES auquel se 
refere ESID. 

15 Chaque unite d'accfes du flux courant pointera les unites d'accfes sur TES 

dont Tidentifiant est ESID appeie ES_base au moyen de DependencyPointers en 
reference aux unites d'accfcs de ESJ>ase (identify par ESID) & travers leur DTS. 

7 .3 Mode TPMP (mode 3} 

Les DependencyPointers sont transmis au sysfeme IPMP avant decodage. 
20 Ces pointeurs opaques permettent aux moyens IPMP de decider s'il est possible 
ou non de decoder l'unite d'accfcs. D peut r6pondre negativement si les clefs n'ont 
pas ete re9ues, ou si les droits ne le permettent pas. Ce pointeur de dependance 
est lie & l'unite de composition apr&s decodage. 

II reviendra au systfcme IPMP avant composition, les moyens IPMP 
25 decidant ensuite si l'unite peut etre ou non presentee. 

8. Flux de reference horloee 

Un flux eiementaire de streamType = ClockReferenceStream doit etre 
declaim au moyen du descripteur d'objet. II est utilise dans le but de transporter les 
30 estampilles temporelles de reference d'horloge objet. De multiples flux 
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dtementaires dans un ensemble de nom peuvent faire r6f6rence h un tel 
ClockReferenceStream au moyen de r€16ment de syntaxe OCR_ES_ID dans le 
SLConf igDescriptor pour 6viter la transmission r6p6t6e de Tinformation 
de reference horloge. Notons, cependant, que des r6f ferences circulaires entre les 
5 flux 616mentaires utilisant OCR_ES_I D ne sont pas permises. 

Sur la couche de synchronisation, un ClockReferenceStream est r€alis6 en 
configurant la syntaxe de Tentete de paquet SL pour ce flux empaquetg au niveau 
SL de telle manifere que seules les valeurs OCR des OCRre solution et 
OCRlength requis sont presents dans Tentete de paquet SL. 

10 II n'y a aucune charge de paquet SL pr^sente dans un flux empaquet6-SL 

de streamType = ClockReferenceStream, 

Dans le DecoderConf igDescriptor pour un flux de reference 
horloge, ObjectTypelndication doit etre mis sur *0xFF\ 
hasRandomAccessUnitsOnlyFlag sur un et buf f erSizeDB sur 'O'. 

15 La suite indique les valeurs recommanddes pour le 

SLConf igDescriptor d'un flux de reference horloge : 

Table 3 - SLConfigDescriptor valeurs des paramfctres SLConfigDescriptor d'un 



pour un ClockReferenceStream 



useAccessUnitStartFlag 


0 


useAccessUnitEndFlag 


0 


useRandomAccessPointFlag 


0 


usePaddingFlag 


0 


useTimeStampsFlag 


0 


useldleFlag 


0 


durationFlag 


o 


timeStampResolution 


0 


timeStampLength 


0 


AU_length 


0 


degradationPriorityLength 


0 
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AU_s e qNumLength 



9. Restrictions pour des flux a^mentaires oartageant le meme obiet de 
base temporelle 

Lorsqu'il est possible de partager un objet de base temporelle entre 
5 plusieurs flux 616mentaires a travers OCR_ES_I D, un nombre de restrictions pour 
Facets & ces flux 616mentaires et & leur traitement existent, comme suit : 

Quand plusieurs flux 616mentaires partagent un simple objet de base 
temporelle, les flux 616mentaires sans information de reference horloge objet 
int6gr£e ne doivent pas.Stre utilises par le terminal, m6me s'ils sont 
10 accessibles, jusqu' h ce que le flux €16mentaire transportant Finformation de 

reference horloge objet devienne accessible. 

Si un flux 616mentaire sans information de reference horloge objet int6gr6e est 
rendu disponible au terminal aprfes le flux 616mentaire transportant 
Tinformation de reference horloge objet, il doit 6tre d61ivr6 en 
15 synchronisation avec le(s) autre(s) flux. Notons que cela implique qu'un tel 

flux ne doive pas gtre d61ivr£ depuis son dfibut, en fonction de la valeur 
courante de Tobjet de base temporelle. 

Quand un flux 616mentaire transportant une information de reference horloge 
objet devient indisponible ou est utilise par ailleurs (par exemple en pause) 
20 tous les autres flux 616mentaires qui utilisent le meme objet de base 

temporelle doivent suivre cette approche, c ! est-&-dire devenir indisponibles 
ou etre manipul6s dans le meme sens. 

Lorsqu'un flux 616mentaire sans information de reference horloge objet int6gr6e 
devient indisponible, cela n*a pas d'incidence sur les autres flux 
25 616mentaires qui partagent le mSme objet de base temporelle. 

10. Utilisation des options de configuration pour les references d'horloge 
et les valeurs d'estamnilles temnorelles 
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10.1 Resolution de rambiguite dans la recuperation d'un objet de base 
temporelle 

Du fait de la longueur limine des valeurs objectClockRef erence 
ces estampilles temporelles peuvent etre ambigues. La valeur temporelle OTB 
5 peut etre reconstruite chaque fois qu'un objectClockRef erence est 
transmis dans les entStes d'un paquet SL selon la formule suivante : 
toTBjcconsmtcted= (ob j e c t C 1 o c kRe f e r e n c e / S L . O CRRe s o 1 u t i o n) + 
k*(2 SL * 0CRLength /SL.0CRResolution) 

avec k etant une valeur enti&re indiquant le nombre de boucles. La base 

10 temporelle resultante t^ est mesur6e en secondes . 

Quand le premier obj ectClockRef erence pour un flux eiementaire 
est acquis, la valeur k doit etre mise k un. Pour chaque occurrence suivante de 
obj ectClockRef erence la valeur k est estim6e comme suit : 

Le terminal doit comprendre des moyens pour estimer la valeur de Tobjet 

15 de base temporelle k chaque instant. 

Chaque fois qu'un ob j.ectClockRef erence est re?u, la valeur 
estim6e courante de TOTB doit gtre 6chantillonn6e. Mors, torju_j ec (k) est 

6valu6 pour diff6rentes valeurs de k. La valeur k qui minimise le terme I t^rB^^cd 
- toro^Ck)! doit etre consider comme la valeur correcte de t^ -rccoa8tnlctcd , Cette 

20 valeur doit etre utiiis^e comme un nouvel apport au m6canisme d'estimation de 
Tobjet de base temporelle. 

L* application doit garantir que cette procedure produit une valeur non 
ambigue de k en seiectionnant une longueur et une resolution appropriees de 
F element objectClockRef erence et une frequence suffisamment £levde 

25 des valeurs d'insertion de obj ectClockRef erence dans le flux eiementaire. 
Les choix pour ces valeurs dependent de la gigue de deiivance pour les paquets 
SL ainsi que de T£cart maximum pr6vu entre les horloges du terminal 
transmetteur et receveur. 

10.2 Resolution de rambiguite dans la recuperation de Testampille temporelle 
30 Du fait de la longueur limitee des valeurs decodingTimeStamp et 
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compositionTimeStamp ces estampilles temporelles peuvent devenir 
ambigues, comme le montre la formule suivante : 
t^mMTimeStamp/SL. timeStampResolution^^ 
SL . timeStampResolution) 
5 avec TimeStamp 6tant soit un decodingTimeS tamp soit un 
compositionTimeStamp et m 6tant une valeur entifcre indiquant le nombre 
de boucles. 

La valeur correcte de l'estampille temporelle peut Stre estim6e 

comme suit : 

10 Chaque fois qu'un TimeStamp est re9U, la valeur estim6e courante de 

l'OTB t^ esu^ted doit £tre 6chantillonn6e. t^m) est 6valu6 pour difffrentes valeurs 
de m. La valeur m qui minimise le terme I W cstiinatcd - t^m)! est consid6r6e 
comme la valeur correcte de t timcstamp . 

L'application peut choisir, separ6ment pour chaque flux 616mentaire 

15 individuel, la longueur et la resolution des estampilles temporelles, afin de 
respecter ses exigences sur le positionnement non ambigu des 6v6nements 
temporels. Ce choix depend du temps maximum pendant lequel un paquet SL 
avec un TimeStamp peut 6tre envoy 6, aprfes le moment indiqud par le 
TimeStamp , ainsi qu*& la precision demandde au positionnement temporel. 

20 10,2 remarques sur 1'usage des references d'horloge objet et des estampilles 
temporelles 

La ligne temporelle d'une base de temps objet permet de distinguer deux 
instants s6par6s par plus d'l/SL.OCRResolution . OCRResolution doit 
etre choisi suffisamment grand pour obtenir la precision dont a besoin 
25 Tapplication pour synchroniser un ensemble de flux €l£mentaires. 

Les estampilles temporelles et de composition permettent de distinguer 
deux instants s6par£s par plus d'l/SL. timeStampResolution . 
timeStampResolution doit Stre choisi suffisamment grand pour obtenir la 
pr6cision dont a besoin l'application en terme de rep6rage des unites d'acc&s pour 
30 un flux 616mentaire donn£. 
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Un TimeStampResolution plus 61ev6 que le OCRResolution ne 
permettra pas d'obtenir une meilleure discrimination entre les 6v6nements. Si 
TimeStampResolution est plus faible que le OCRResolution, les 
6v6nements pour ce flux sp6cifique ne peuvent pas 6tre rep6r6s avec la precision 
5 maximum possible avec ce OCRRe solution donn6 . 

Le paramfctre OCRLength est signal^ dans la configuration de Pentete 
SL. 2 SL 0CRLength /SL .OCRResolution est Tintervalle de temps couvert par 
le compteur objectClockRef erence avant qu'il boucle. OCRLength doit 
Stre choisi suffisamment 61ev6 pour respecter les besoins de Implication pour un 
10 positionnement non ambigu des 6v6nements temporels pour un ensemble de flux 
616mentaires. 

Lorsqu'une application connait la valeur k d6finie plus haut, la ligne 
temporelle OTB est claire pour chaque valeur temporelle. Quand 1' application ne 
peut pas reconstruire le facteur k, comme par exemple dans une application qui 

15 permet Taccfes al6atoire sans information compl6mentaire, la ligne temporelle 
OTB est ambigue modulo 2 SL * 0CRLength /SL .OCRResolution. Ainsi, chaque 
estampille temporelle se i£f6rant k cet OTB est ambigue. II peut, cependant, Stre 
consider clair h Tint6rieur d'un environnement d' application & travers la 
connaissance de la gigue maximum suppos6e et des contraintes sur la dur€e 

20 pendant laquelle une unit6 d*accfes peut etre envoySe avant son instant de 
d£codage. 

Notons que les flux 61€mentaires qui choisissent un intervalle de temps 
2SL.timestam P Length/ gL ^ t imeStampResolution sup&ieur que 
2 sl .OCRLength/ SL .OCRResolution ne peuvent rep6rer de fagon non ambigue 
25 les 6v6nements temporels que dans le plus petit des deux intervalles. 

Dans certains cas, lorsque k et m ne peuvent gtre estim^s correctement, le 
module tampon peut etre transgress^, ce qui entraine des op6rations et des 
r€sultats impr^visibles du dgcodeur. 

Par exemple, si on considfere une application qui veut synchroniser les flux 
30 616mentaires avec une precision d'l ms, OCRResolution doit etre choisi 6gal ou 
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sup^rieur k 1000 (le temps entre deux impulsions successives de l'OCR est alors 
6gal k 1ms). Supposons OCRResolution=2000. 

L'application suppose une gigue entre le STB et le OTB de 0.1% (c*est-&- 
dire 1ms par seconde). Les horloges doivent par consequent 8tre ajustgs au moins 
5 chaque seconde (c'est-&-dire, dans le pire des cas, que les horloges auront d6vi6 
d'lms, ce qui est la contrainte de precision). Supposons que des 
objectClockReference sontenvoy6s chaque Is. 

L'application veut avoir une ligne temporelle OTB claire de 24h sans avoir 
besoin de reconstruire le facteur k. Le OCRLength est alors choisi en 
10 consequence de meme que 2 SL 0CRLength /SL •OCRResolution=24h. 

Supposons maintenant que Fapplication veut synchroniser les £v£nements 
a l'intSrieur d'un flux 616mentaire seul avec la precision de 10 ms. 
Times tampResolution doit etre choisi £gal ou sup€rieur k 100 (le temps 
entre deux impulsions successives du Time St amp est alors £gal & 10ms). 
15 Supposons TimeStampResolution=200. 

L'application veut Stre capable d'envoyer les unites d'accfcs k un 
maximum d'une minute avant leur temps d£codeur ou de composition. Le 
timeStampLength est alors choisi comme 

2 SL# timestam P Length /SL ^ t imeStampResolu t ion = 2 minutes. 

20 
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REVENDICATIONS 

1. Proc&te de transmission d'au moins un flux de dorutees vers au moins un 
terminal, le ou lesdits flux 6tant organises en unites de flux, 
caracterisS en ce qu'au moins certaines desdites unites de flux comprennent au 
5 moins un pointeur pointant vers au moins une unite de flux dudit flux ou d'un 
autre flux susceptible d'avoir 6t6 re$ue pr6c6demment dans un terminal, dite unite 
anterieure n6cessaire, 

de fa9on qu'un traitement de ladite unite de flux ne soit pas effecnte, dans ledit 
terminal, si la ou lesdites unites anterieures n6cessaires n'ont pas 6te re?ues. 

10 2. Proc&te de transmission selon la revendication 1, caracteris6 en ce qu'il 
comprend la transmission d'au moins deux flux de donn^es transmis s6par6ment, 
une unite de flux d'un premier flux pointant vers au moins une unite anterieure 
n^cessaire d'au moins un second flux, ladite unite de flux du premier flux 
comprenant des donn€es d'enrichissement des donn€es contenues dans le ou 

15 lesdits seconds flux. 

3. Proc6d6 de transmission selon la revendication 2, caracteris6 en ce que 
lesdits flux de donn^es correspondent k des niveaux hterarchiques diffSrents d'un 
codage hterarchique, le traitement d'une unite de flux d'un niveau hterarchique 
domte n'Stant effecttte que si les unites de flux du ou des niveaux hterarchiques 

20 inf&ieurs correspondants ont 6te re$us. 

4. Proc6d6 de transmission selon Tune quelconque des revendications 2 et 3, 
caracteris6 en ce que ladite unite de flux pointe sur au moins une unite anterieure, 
d^finissant une sequence d'unites anterieures nScessaires. 

5. Proc&te de transmission selon Tune quelconque des revendications 1 & 4, 
25 caracteris6 en ce qu'au moins un desdits pointeurs permet de retrouver au moins 

une unite anterieure n£cessaire comprenant des donn6es permettant le d6codage 
et/ou le d6cryptage de l'unite de flux consid&£e. 

6. Proc6d6 de transmission selon la revendication 5, caracteris6 en ce que la 
ou lesdites unites anterieures n6cessaires comprend des domtees permettant h un 

30 terminal de decider si les domtees d'une unite de flux consid6r6e doivent 6tre 
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d6cod£es et/ou decryptees, puis affich^es apr&s decodage. 

7. Proc6d6 de transmission selon Tune quelconque des revendications 1 & 6, 
caracterise en ce qu'au moins un desdits pointeurs pointent vers des donndes 
susceptibles d'etre connues dudit terminal, de fa9on que ce dernier puisse decider 

5 de sa capacity ou de son incapacity & traiter 1'unite de flux correspondante. 

8. Proc6d6 de transmission selon Tune quelconque des revendications 1 & 7, 
caract6ris6 en ce qu'au moins une desdites unites de flux comprend au moins un 
pointeur pointant vers au moins une unite de flux dudit flux ou d'un autre flux, 
susceptible d'etre regue prochainement. 

10 9. Procede de transmission selon la revendication 8, caracterise en ce que la 
ou lesdites unites de flux susceptible d'Stre re9ue prochainement poss&de en 
marqueur, permettant de faire un lien avec le ou lesdits pointeurs. 

10, Procede de transmission selon Tune quelconque des revendications 8 et 9, 
caracterise en ce que les pointeurs d'au moins deux unites de flux similaires 

15 transmises & des instants distincts pointent vers une meme unite de flux 
susceptible d'Stre re$ue prochainement. 

11, Procede de transmission selon Tune quelconque des revendications 1 & 10, 
caracterise en ce qu'il met en oeuvre un indicateur indiquant le role du ou des 
pointeurs, parmi au moins deux des r61es appartenant au groupe comprenant : 

20 - designation d*au moins une unite de flux anterieure devant gtre 

d6cod6e pour permettre la prise en compte de l'unite de flux 
consid£r£e ; 

designation d'au moins une unite de flux anterieure comprenant des 
donn£es n^cessaires au decodage et/ou au decryptage de l'unite de 
25 flux consider, et/ou d'une reference h un etat d'un systfcme de 

protection ; 

designation d'au moins une unite de flux posterieure. 

12, Procede de transmission selon la revendication 11, caracteris6 en ce qu'au 
moins certaines desdites unites de flux comprennent un descripteur de 

30 dependance, deflnissant ledit rdle. 
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13. Proc6d£ de transmission selon Tune quelconque des revendications 1 k 12, 
caract£ris£ en ce qu'au moins certaines desdites unites de flux comprennent un 
marqueur de d€pendance, permettant son identification en tant qu'unit6 ant&ieure 
n^cessaire. 

5 14. Proc6d6 de transmission selon Tune quelconque des revendications 1 &13, 
caract6ris£ en ce qu'au moins certaines desdites unites de flux comprennent un 
marqueur d'identification de ladite unit6 de flux dans ledit flux. 

15. Proc6d6 de transmission selon Tune quelconque des revendications 1 k 14, 
caract6ris6 en ce qu'il est mis en ceuvre au niveau synchronisation, de fagon 

10 qu'aucun traitement prgalable d'une unit6 de flux regue ne soit n6cessaire. 

16. Flux de donn6es transmis selon le proc€d6 de transmission de Tune 
quelconque des revendications 1 k 15. 

17. Flux de donn^es transmis vers et/ou requ par au moins un terminal, et 
organis6 en unites de flux transmises ind£pendamment les unes des autres, 

15 caract6ris€ en ce qu'au moins certaines desdites unites de flux comprennent au 
moins un pointeur pointant vers au moins une unit6 de flux dudit flux ou d'un 
autre flux susceptible d'avoir 6t6 re§ue prdc6demment dans un terminal, dite unit6 
ant&ieure ndcessaire, 

de fagon qu'un traitement de ladite unite de flux ne soit pas effectu6, dans ledit 
20 terminal, si la ou lesdites unites ant&ieures n€cessaires n'ont pas 6x6 regues. 

18. Serveur de donn6es destinies k £tre transmises vers au moins un terminal, 
sous la forme d'au moins un flux de donn^es organis6 en unites de flux transmises 
ind£pendamment les unes des autres, 

caract£ris£ en ce qu'au moins certaines desdites unites de flux comprennent au 
25 moins un pointeur pointant vers au moins une unit6 de flux dudit flux ou d'un 
autre flux susceptible d'avoir 6t6 re$ue prdcddemment dans un terminal, dite unitd 
ant&ieure ngcessaire. 

19. Terminal apte k recevoir au moins un flux de donnges organist en unites 
de flux transmises ind€pendamment les unes des autres, 

30 caract6ris6 en ce qu'au moins certaines desdites unites de flux comprennent au 



WO 03/077561 




PCT/FR03/00754 



moins un pointeur pointant vers au moins une unit6 de flux dudit flux ou d'un 
autre flux susceptible d'avoir 6t6 re9ue pr6c6demment dans un terminal, dite unite 
antSrieure n6cessaire. 

20. Proc6d6 de reception d'au moins un flux de donn6es organist en unites de 
5 flux transmises ind6pendamment les unes des autres, 

caract€ris6 en ce qu'au moins certaines desdites unites de flux comprennent au 
moins tin pointeur pointant vers au moins une unit6 de flux dudit flux ou d'un 
autre flux susceptible d'avoir €t€ re$ue pr6c6demment dans un terminal, dite unit6 
ant£rieure n^cessaire. 

10 21. Proc6d6 de reception selon la revendication 20, caract£ris6 en ce qu'au 
moins un desdits pointeurs pointe vers au moins une unit6 de flux dudit flux ou 
d'un autre flux susceptible d'avoir 6t6 r&pie pr6c6demment dans un terminal, dite 
unite ant&ieure nScessaire, 
et en ce qu*il comprend les Stapes suivantes : 

15 - analyse du ou desdits pointeurs d'une unit6 de flux ; 

traitement de ladite unit6 de flux si la ou lesdites unites anterieures 
n6cessaires ont 6t6 regues. 
22. Utilisation du proc6d6 de transmission selon Tune quelconque des 
revendications 1 i 15 pour une des applications appartenant au groupe 

20 comprenant : 

diffusion syst^matique d'un message avant acc&s h un programme 
s61ectionn6 par un utilisateur ; 

acc&s conditionnel & un niveau de quality particulier et/ou & une 
option particulifcre d'un programme ; 
25 - television interactive. 
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